Typesafe IPC #331
Typesafe IPC #331
Conversation
No. You may break as many things as you want :) |
|
I noticed couple |
|
This should conclude first part if IPC refactor. In next PR I will reorganize daemon and client a bit to facilitate easier adjustments. |
Wayland is already being used by some people in FreeBSD. They've even opened issues in this project. Furthermore, in general, Wayland isn't Linux-specific. There was a time where |
| use std::env; | ||
| use std::marker::PhantomData; | ||
| use std::sync::OnceLock; | ||
| use std::time::Duration; | ||
|
|
||
| use rustix::fd::OwnedFd; | ||
| use rustix::io::Errno; | ||
| use rustix::net; | ||
|
|
||
| use super::ErrnoExt; | ||
| use super::IpcError; | ||
| use super::IpcErrorKind; |
There was a problem hiding this comment.
Is there a reason why you are doing imports like this? I don't particularly mind, but it isn't consistent with the rest of the codebase. I supposed we could normalize them later...
There was a problem hiding this comment.
I simply prefer this style. When I change imports, the resulting diff is on one line (with entire path). Also, I think it is easier to parse (entire path in one spot, I don't have to jump around to see who declared something like fs module) and edit in general (dd in vim).
Alright. And as for |
They are there to avoid copies. By memory mapping them we have only one shared memory buffer between the client and the daemon. Also, we won't be using serde, at all. Serde does a bunch of unnecessary copies around, and increases our dependencies significantly due to everything we have to pull. It's really good for large applications where writing everything manually would be a pain, or simply when you don't want to bother. But I went to great lengths to make IPC as efficient as I could. Our serialization and de-serialization will remain all manual. I believe the easiest way of making the code more readable would be by using something like a builder pattern. You wrap |
|
Sorry, that's not really what I meant. By serde I meant reading and writing messages to the shared buffer (without a protocol). But when receiving and deserializing data, I noticed tho two aforementioned types being built. Is there a reason not to create EDIT: |
|
Ah, I get it now, my bad. I don't 100% remember what the problem was, but I believe it was that, when we send in an animation, we will have the image bytes and the animation bytes all mapped, and I wanted to unmap just the image bytes and keep the animation bytes. In any case, if you think you can simplify the logic by removing them, go ahead and give it a try! |
This is first (and probably not last) PR for IPC refactor. For now this is a draft because I am unsure if PRs of this size are either to big or too inconsequential.
Apart from sending and receiving itself, I will take a look at some semi-duplicated code (looking at you,
RequestSendandRequestRecv), though this will not be included in this PR.Is there any form of compatibility guarantee between swww and swww-daemon if version bump ocuurs?